The proliferation of distributed computing networks and, in particular, wireless communication networks has brought with it a greater need to secure the information that is transmitted through the networks. For example, the computing power and storage capacity now available in end-user devices such as cell phones and wireless PDAs makes them a convenience mechanism for storing and using sensitive information (e.g., personal and business contact and financial information). However, to store and use this information on an end-user device, a user may need to transmit the information to and from other locations (e.g., a server) via a relatively insecure network.
A variety of cryptographic techniques are known for securing transactions in data networks. For example, the SSL protocol (and its replacement TLS) provides a mechanism for securely sending data between a server and a client. Briefly, the SSL provides a protocol for authenticating the identity of the server and the client and for generating an asymmetric (private-public) key pair. The authentication process provides the client and the server with some level of assurance that they are communicating with the entity with which they intended to communicate. The key generation process securely provides the client and the server with unique cryptographic keys that enable each of them, but not others, to encrypt or decrypt data they send to each other via the network.
This process may be better understood by reference to FIG. 1 which is an abstract drawing 100 of several layers in a security system 102. Entities in the system may securely transfer data between one another by encrypting the data 104 before it is transmitted. Before another entity is able to decrypt received data, however, it must obtain an appropriate key. Hence, data encryption may depend on a secure method of key negotiation 106 between the entities. If the key negotiation is not secure (e.g., the keys are intercepted by unauthorized persons), the encrypted data may be compromised. Consequently, a prerequisite to secure key negotiation may be the ability to authenticate the parties 108 involved in the exchange. In other words, each entity must be sure that it is not negotiating with an entity that is, for example, masquerading as the intended entity. The authentication process ultimately relies on a root key 110 that uniquely and reliably identifies a specific entity. Hence, this root key is often referred to as the cryptographic identity of the entity.
In practice, a system may include many levels of cryptographic protection. For example, a typical e-commerce server may need to negotiate keys with thousands of clients per day. Moreover, these clients typically reside in relatively insecure environments (e.g., personal computers) If the system is to remain secure, the root key should not be used for these transactions given that there is a relatively high possibility that the key may be compromised. Accordingly, in practice the root key is used to generate other keys that may then be used to generate even lower level keys.
Typically, these lower level keys will be used for relatively short periods of time. For example, lower level keys such as SSL session keys may be valid only for a single session. Thus, the potential for damage may be much less when a session key is compromised as opposed to when a higher level key is compromised. For example, in the former case the entire system will not be compromised and the key will expire relatively quickly.
In contrast, once a higher level key is compromised, all subsequent (e.g., lower) levels may be compromised. Moreover, higher level keys tend to be used for relatively long periods of time. Thus, the potential for harm is much greater. Accordingly, protection of higher level keys is a primary goal in any cryptographic security system.
As mentioned above, in a typical e-commerce transaction a unique set of SSL keys are generated for each session. For example, when a user uses a web browser to securely access a financial website for a bank, a set of session keys may be generated for the session. These session keys are used to encrypt and decrypt data sent between the server (e.g., the bank's server) and the client (e.g., the browser). To prevent these keys from being intercepted by unauthorized persons, a higher level key (e.g., a private-public key pair negotiated between the bank's server and the client) will be used to encrypt and decrypt the session level keys. As discussed above, however, protection of this higher level key is of utmost importance.
Referring to FIG. 2, in a typical personal computer-based application, a client device stores its private key (Ka-priv) 214 in a system memory 206 of a computer 200. To reduce the complexity of FIG. 2, the entire computer 200 is not shown. When a session is initiated, the server encrypts the session key (Ks) 228 using the client's public key (Ka-pub) then sends the encrypted session key (Ks)Ka-pub 222 to the client. As represented by lines 216 and 224, the client then retrieves its private key (Ka-priv) 214 and the encrypted session key 222 from the system memory 206 via the PCI bus 208 and loads them into a public key accelerator 210 in an accelerator module or card 202. The public key accelerator 210 uses this downloaded private key (Ka) 220 to decrypt the encrypted session key 222. As represented by line 226, the public key accelerator 210 then loads the clear text session key (Ks) 228 into the system memory 206.
When the server needs to send sensitive data to the client during the session the server encrypts the data using the session key (Ks) and loads the encrypted data [data]Ks 204 into system memory. When a client application needs to access the plaintext (unencrypted) data, it may load the session key 228 and the encrypted data 204 into a symmetric algorithm engine (e.g., 3DES, AES, etc.) 212 as represented by lines 230 and 234, respectively. The symmetric algorithm engine 212 uses the loaded session key 232 to decrypt the encrypted data and, as represented by line 236, loads plaintext data 238 into the system memory 206. At this point the client application may use the data 238.
The SSL protocol and other protocols provide a relatively high level of security for data transfers when both the client and the server are secure. However, given the increased sophistication of hackers and authors of computer viruses, there is a possibility that the security of these devices may be comprised. For example, a virus running on a computer may be able to access data stored in the data memory of the computer. Moreover, the virus may be able to send this information to a third party.
Referring again to the example of FIG. 2, the client's private key (Ka-priv) 214 may be stored in the clear (e.g., unencrypted) in the system memory 606 and it may be transmitted in the clear across the PCI bus 614. Moreover, operating system calls may be used to provide the data transfers to and from the cryptographic accelerator 210. All of these aspects of the system are susceptible to attack by hackers, viruses or other means. Given that in an SSL transaction the client's private key is essentially a certificate that identifies the server (hence it may essentially comprise the server's private key), conventional architectures such as this may not provide sufficient security for many applications.
Components such as a hardware security module (“HSM”) may be used to provide a higher level of security for applications that are very security-sensitive. Conventionally, a hardware security module provides secure key management to generate cryptographic keys, sets the capabilities and security limits of keys, implements key backup and recovery, prepares keys for storage and performs key revocation and destruction. These modules are typically constructed as multi-chip boards potted with an epoxy material to provide very strong security. However, due to the use of the epoxy material and the functional key management requirements, a hardware security module is typically a very expensive device that has a large system footprint and has limited capabilities outside of key management.
Due to these constraints, it may be impractical to implement a hardware security module into many types of network components, particularly end-user devices. Accordingly, a need exists for improved techniques for securing data that is used by end-user devices and/or is transmitted through a data network.